REMARKS 

Claims 1-44 are pending in the application. Claims 1, 40, 41, and 43 are independent 
claims. Claims 1-44 stand rejected by the examiner. Assignee traverses the instant claim 
rejections. 

Examiner's Interview 

Assignee's representatives would like to thank examiner Sheng-Jen Tsai for the 
courtesies extended to assignee's representatives (Charles Shorb, Timothy Wilson, and John 
Biernacki) during the telephone interview on October 25, 2007. The interview discussed the 
cited references Daynes (USPN 6,343,339) and Ofer (USPN 6,691,194) and more specifically 
the office action's position provided on page 6 regarding claim 44 and which related to the term 
"concurrent access." The term was discussed in the interview in view of the definition of the 
term "concurrent" from the Microsoft Computer dictionary (1994) and which was provided to 
the examiner for the interview. The examiner indicated that the interview and the definition 
from the Microsoft dictionary overcame the rejection of claim 44 under 35 U.S.C. § 1 12 and thus 
the rejection was to be removed. 

Other items addressed during the interview included: discussion of the comment on page 
4 of the office action regarding certain drawbacks of the Daynes' method and apparatus; and 
discussion that Ofer is significantly different because, among other things, Ofer does not allow 
for multiple executable entities' access to be concurrent with respect to a resource. The remarks 
and the amendments contained herein further summarize the interview. 
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Rejections - 35 U.S.C. §103 

Claims 1-27 and 32-44 stand rejected under 35 U.S.C. § 103 as being unpatentable over 
U.S. Patent No. 6,343,339 to Daynes ("Daynes") in view of U.S. Patent No. 6,691,194 to Ofer 
("Ofer"). Claims 28-31 stand rejected under 35 U.S.C. § 103 as being unpatentable over Daynes 
in view of Ofer further in view of U.S. Patent No. 6,480,918 to McKenney et al. ("McKenney"). 
These rejections are traversed. 

As discussed during the interview, claim 1 is directed toward a memory for storing a 

computer-implemented shared locking data store for handling multiple executable entities' 

access to at least one resource. Claim 1 recites (in combination with its other limitations) that 

encapsulation of both lock status data and the reader data in the shared locking data store allows 

a hardware atomic operation to operate upon both the lock status data and the reader data as a 

single unit for determining how access to the resource is to be handled. This allows the access to 

the resource to be concurrent. Claim 1 has been amended to emphasize this aspect by including 

a limitation that was in dependent claim 44. This limitation reads: wherein the multiple 

executable entities' access is a concurrent access to the at least one resource. As discussed 

during the interview, concurrent is defined in the Microsoft computer dictionary as follows: 

concurrent A term applied to a computer operation in which two or 
more processes (programs) have access to the microprocessor's time and 
are therefore carried out more or less at the same time. Because a 
microprocessor can work with much smaller units of time than people can 
perceive, concurrent processes appear to be occurring simultaneously but 
in reality are not. 

Assignee respectfully disagrees that the Ofer reference discloses such limitations of claim 1 . For 
example, the Ofer reference is directed toward a method and apparatus for improving 
performance in a system where multiple processors contend for control of a shared resource. 
The Ofer reference defines the term shared resource according to a resource's visibility to the 
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multiple processors. (See Ofer column 1 lines 15-25.) Accordingly, the shared resource 
disclosure in Ofer is to be differentiated from the type of shared access required in claim 1 : a 
shared resource in Ofer only requires that a resource be visible to multiple executing entities (e.g., 
threads), whereas shared access allows the resource to be used concurrently (as defined above 
and as recited in claim 1) by multiple executing entities (e.g., threads). 

Further, Ofer limits access to the shared resource to a single processor. (See Ofer column 
3 lines 66-67 and column 4 lines 1-20.) Accordingly the method and apparatus disclosed in Ofer 
does not allow for multiple executable entities' access to be concurrent with respect to a resource 
as required by claim 1 . Several other of the dependent claims also clarify this distinction. For 
example, claim 3 describes determination of access to the resource, and claims 8 and 9 
respectively describe the rules mechanism associated with allowing both shared access (e.g., any 
number of read requests) and exclusive access (e.g., only one writer). 

With respect to the Daynes reference, the Daynes reference discloses an approach which 
is incompatible with the atomic approach recited in claim 1 . For example, the Daynes reference 
defines the locking mode according to how the lock is accessed. The Daynes reference then 
defines the lock state as the set of the values of each of the owners of a the lock. (See Daynes 
column 8 lines 25-36.) The method and apparatus disclosed by Daynes uses a dedicated bitmap 
for each locking mode. When read and write locking modes are used, a lock state contains a read 
bitmap and a write bitmap. (See Daynes column 15 lines 2-5.) More specifically, the disclosed 
approach requires the enumeration of the task to be unique, a requirement for the creation and 
maintenance of the Table of Immutable States. Attempting to map operating threads to a limited 
number of tasks slots in a unique identifier fashion within the Table of Immutable States space 
becomes problematic such that the approach in Daynes results in much larger data usage 
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requirements that is incompatible with the atomic approach recited in claim 1 - that is, because 
in claim 1 the lock data is encapsulated into a single atomic operation, memory consumption and 
processing costs on the system decrease regardless of whether or not redundant lock states are 
present. 

Because of such significant differences between the approach in the Daynes reference 
and the Ofer reference (whether considered alone or in combination with the other reference), 
claim 1 is patentable and should be allowed. Independent claims 40, 41, and 43 recite similar 
limitations as claim 1. Accordingly, assignee respectfully asserts that the rejections for these 
claims be withdrawn and that the claims be allowed. 



For the foregoing reasons, assignee respectfully submits that the pending claims are 
allowable. Therefore, the examiner is respectfully requested to pass this case to issue. 



CONCLUSION 



Respectfully-submitted, 




JoM V. Biernacki 
Rfg. No. 40,511 
JONES DAY 
North Point 
901 Lakeside Avenue 
Cleveland, Ohio 44114 
(216)586-3939 



Dated: 
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